System and Method for Mobility Management in a Wireless Communications System

ABSTRACT

A system and method for mobility management in a wireless communications system are provided. A method for proxy server operations includes determining if a communications device is capable of performing an operation, forwarding a transmission to a destination of the transmission if the communications device is capable of performing an operation, and responding to the transmission on behalf of the communications device if the communications device is not capable of performing an operation.

This application is a divisional of U.S. patent application Ser. No.13/084,956, filed Apr. 12, 2011, entitled “System and Method forMobility Management in a Wireless Communications System,” which claimsthe benefit of U.S. Provisional Application No. 61/447,409, filed onFeb. 28, 2011, entitled “System and Method for Mobility Management in aWireless Communications System,” which applications are herebyincorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to digital communications, andmore particularly to a system and method for mobility management in awireless communications system.

BACKGROUND

Wireless communications systems have changed the way that their userswork and enjoy information access. No longer are users of wirelessbroadband access systems restricted to specific locations with wirelineaccess to information services. In fact, users are free to move whereverthey like within a coverage area and still have rapid access toinformation that they need and/or desire.

Currently available wireless communications system utilize a singleidentifier, usually an Internet Protocol (IP) address, to identify acommunications device as well as to address (route information to andfrom) the communications device. The use of a single identifier maycomplicate device mobility since as the communications device movesabout, it may be necessary to handover the communications device from afirst access network to a second access network, thereby potentiallyresulting in a different identifier. The use of the different identifiermay complicate locating the communications device.

A variety of newly proposed protocols, such as Host Identity Protocol(HIP) defined by the Internet Engineering Task Force (IETF), separatethe single identifier into two identifiers, with a host identifier(e.g., a host identity) to be used for network session identification,and an IP address for addressing purposes. In addition to simplifyinglocating a communications device, the use of two identifiers may alsoprovide better security support, as well as a framework with which amechanism for mobility management may be designed.

However, supporting the dual identifier protocols, such as HIP, mayrequire modifications to the IP protocol stack at hosts (also commonlyreferred to as communications devices, mobiles, mobile stations,terminals, users, subscribers, and so on). Requiring upgrades to hostsmay be an expensive (if not impossible) proposition. A HIP proxy (orequivalently, a HIP proxy server) provides HIP function includingsecurity features by the network without requiring modifications to thehost, yet it is still necessary to design the appropriate mobilitymanagement mechanisms that will improve the handover performance.

Additionally, existing mobility support mechanisms with the dualidentifier protocols, such as HIP, suffer from long handover delay dueto signaling overhead, such as duplicate address detection (DAD),location update, security signaling, and so forth.

Therefore, there is a need for a system and method for providingmobility management in a wireless communications system withoutrequiring upgrades to hosts, i.e., provides support for legacy hosts.

SUMMARY OF THE INVENTION

These and other problems are generally solved or circumvented, andtechnical advantages are generally achieved, by example embodiments ofthe present invention which provide a system and method for mobilitymanagement in a wireless communications system.

In accordance with an example embodiment of the present invention, amethod for proxy server operations is provided. The method includesdetermining if a communications device is capable of performing anoperation, forwarding a transmission to a destination of thetransmission if the communications device is capable of performing anoperation, and responding to the transmission on behalf of thecommunications device if the communications device is not capable ofperforming an operation.

In accordance with an example embodiment of the present invention, aproxy server is provided. The proxy server includes a host determiningunit, a forwarding unit coupled to the host determining unit, and aresponse unit coupled to the host determining unit. The host determiningunit determines if a communications device is capable of performing anoperation, the forwarding unit forwards a transmission to a destinationof the transmission if communications device is capable of performing anoperation, and the response unit responds to the transmission on behalfof the communications device if the communications device is not capableof performing an operation.

In accordance with an example embodiment of the present invention, amethod for proxy server operations is provided. The method includesdetermining that a communications device is attaching to acommunications system, updating binding information for thecommunications device at a server, and configuring an addressingidentifier for the communications device. The binding informationincludes an identifier for the communications device.

In accordance with an example embodiment of the present invention, aproxy server is provided. The proxy server includes a packet processingunit, a binding information managing unit coupled to the packetprocessing unit, and an addressing unit coupled to the packet processingunit. The packet processing unit determines if a communications deviceis attaching to a communications system, the binding informationmanaging unit manages changes in the binding information, and theaddressing unit configures an addressing identifier for thecommunications device.

In accordance with an example embodiment of the present invention, amethod for proxy server operations is provided. The method includesdetermining that a communications device is detaching from acommunications system, updating binding information for thecommunications device at a server, and providing binding information forthe communications device to neighboring proxies.

One advantage disclosed herein is that only a small number of high levelnetwork components require upgrading to provide support for legacyhosts. Therefore, implementation costs and complexity may be kept to aminimum. As an example, existing hosts (i.e., legacy hosts) alreadyinstalled in a communications system will continue to be supported as amigration to HIP enabled hosts occur. Therefore, existing equipment donot need to be immediately replaced.

A further advantage of exemplary embodiments is that a hierarchicalbinding information structure is utilized to help reduce lookupoverhead, handover overhead, and so forth.

A further advantage of exemplary embodiments is that it is possible toco-locate the mobility management function only at the access router. Itwill then achieve all the benefits of this disclosure but for HIP hostonly, not non-HIP host.

The foregoing has outlined rather broadly the features and technicaladvantages of the present invention in order that the detaileddescription of the embodiments that follow may be better understood.Additional features and advantages of the embodiments will be describedhereinafter which form the subject of the claims of the invention. Itshould be appreciated by those skilled in the art that the conceptionand specific embodiments disclosed may be readily utilized as a basisfor modifying or designing other structures or processes for carryingout the same purposes of the present invention. It should also berealized by those skilled in the art that such equivalent constructionsdo not depart from the spirit and scope of the invention as set forth inthe appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawing, in which:

FIG. 1 a illustrates an example wireless communications system accordingto example embodiments described herein;

FIG. 1 b illustrates a table 150 of binding information for a MH

FIG. 2 a illustrates an example flow diagram of MHP operations 200 as aMHP receives a packet for a MH according to example embodimentsdescribed herein;

FIG. 2 b illustrates a flow diagram of MHP operations 250 as a MHPreceives a packet from a MH

FIG. 3 illustrates an example wireless communications system 300 withinformation highlights shown for registration of a HIP enabled MH and anon-HIP enabled MH according to example embodiments described herein;

FIG. 4 a illustrates an example diagram 400 of messages exchangedbetween entities in a wireless communications system as a non-HIPenabled MH attaches to the wireless communications system according toexample embodiments described herein;

FIG. 4 b illustrates an example diagram 420 of messages exchangedbetween entities in a wireless communications system as a HIP enabled MHattaches to the wireless communications system according to exampleembodiments described herein;

FIG. 4 c illustrates an example flow diagram of MHP operations 440 forattachment of a HIP enabled MH according to example embodimentsdescribed herein;

FIG. 4 d illustrates an example flow diagram of MHP operations 460 forattachment of a non-HIP enabled MH according to example embodimentsdescribed herein;

FIG. 5 a illustrates an example diagram 500 of messages exchangedbetween entities in a wireless communications system as a non-HIPenabled MH and a CH exchange data traffic, wherein the CH is aninitiator of the exchange according to example embodiments describedherein;

FIG. 5 b illustrates an example diagram 550 of messages exchangedbetween entities in a wireless communications system as a HIP enabled MHand a CH exchange data traffic, wherein the CH is an initiator of theexchange according to example embodiments described herein;

FIG. 5 c illustrates an example flow diagram of MHP operations 590 inthe establishing of a data traffic exchange between a HIP enabled MH anda HIP enabled CH according to example embodiments described herein;

FIG. 5 d illustrates an example flow diagram of MHP operations 595 inthe establishing of a data traffic exchange between a non-HIP enabled MHand a HIP enabled CH according to example embodiments described herein;

FIG. 6 a illustrates an example wireless communications system 600 withinformation highlights shown for a flow of an I1 packet from a CH to aMH according to example embodiments described herein;

FIG. 6 b illustrates an example wireless communications system 650 withinformation highlights shown for a flow of I1, R1, 12, and R2 packetsfrom a CH to a MH according to example embodiments described herein;

FIG. 7 a illustrates an example diagram 700 of messages exchangedbetween entities in a wireless communications system as a non-HIPenabled MH handovers from a current access network and a new accessnetwork with both access networks belonging to a single domain managedby a single LRVS, i.e., an intra-domain handover according to exampleembodiments described herein;

FIG. 7 b illustrates an example flow diagram of current MHP operations760 as a non-HIP enabled MH handovers from a current access network anda new access network with both access networks belonging to a singledomain managed by a single LRVS according to example embodimentsdescribed herein;

FIG. 7 c illustrates an example flow diagram of new MHP operations 780as a non-HIP enabled MH handovers from a current access network and anew access network with both access networks belonging to a singledomain managed by a single LRVS according to example embodimentsdescribed herein;

FIG. 8 a illustrates an example diagram 800 of messages exchangedbetween entities in a wireless communications system as a HIP enabled MHhandovers from a current access network and a new access network withboth access networks belonging to a single domain managed by a singleLRVS, i.e., an intra-domain handover according to example embodimentsdescribed herein;

FIG. 8 b illustrates an example flow diagram of current MHP operations860 as a HIP enabled MH handovers from a current access network and anew access network with both access networks belonging to a singledomain managed by a single LRVS according to example embodimentsdescribed herein;

FIG. 8 c illustrates an example flow diagram of new MHP operations 880as a HIP enabled MH handovers from a current access network and a newaccess network with both access networks belonging to a single domainmanaged by a single LRVS according to example embodiments describedherein;

FIG. 9 a illustrates an example diagram 900 of messages exchangedbetween entities in a wireless communications system as a non-HIPenabled MH handovers from a current access network and a new accessnetwork with the access networks belonging to different domain managedby different LRVS, i.e., an inter-domain handover according to exampleembodiments described herein;

FIG. 9 b illustrates an example flow diagram of current MHP operations960 as a non-HIP enabled MH handovers from a current access network anda new access network with the access networks belonging to differentdomain managed by different LRVS according to example embodimentsdescribed herein;

FIG. 9 c illustrates an example flow diagram of new MHP operations 980as a non-HIP enabled MH handovers from a current access network and anew access network with the access networks belonging to differentdomain managed by different LRVS according to example embodimentsdescribed herein;

FIG. 10 a illustrates an example diagram 1000 of messages exchangedbetween entities in a wireless communications system as a HIP enabled MHhandovers from a current access network and a new access network withthe access networks belonging to different domain managed by differentLRVS, i.e., an inter-domain handover according to example embodimentsdescribed herein;

FIG. 10 b illustrates an example flow diagram of current MHP operations1060 as a HIP enabled MH handovers from a current access network and anew access network with the access networks belonging to differentdomain managed by different LRVS according to example embodimentsdescribed herein;

FIG. 10 c illustrates an example flow diagram of new MHP operations 1080as a HIP enabled MH handovers from a current access network and a newaccess network with the access networks belonging to different domainmanaged by different LRVS according to example embodiments describedherein; and

FIG. 11 provides an example illustration of a communications device 1100according to example embodiments described herein.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The making and using of the current example embodiments are discussed indetail below. It should be appreciated, however, that the presentinvention provides many applicable inventive concepts that can beembodied in a wide variety of specific contexts. The specificembodiments discussed are merely illustrative of specific ways to makeand use the invention, and do not limit the scope of the invention.

The present invention will be described with respect to exampleembodiments in a specific context, namely a wireless communicationssystem that utilizes HIP to provide mobility and security for hostsattached to the wireless communications system. The invention may alsobe applied, however, to other wireless communications systems that makeof protocols that make use of separate identifiers for identificationand routing, such as Identity Locator Network Protocol for IPv6(ILNPv6), Shim6, Host Identity Indirection Infrastructure (Hi3),Internet Indirection Infrastructure (i3), and so forth.

FIG. 1 a illustrates a wireless communications system 100. Wirelesscommunications system 100 makes use of HIP or some other protocol thatsupports dual identifiers for identification and routing purposes, andincludes a domain name server (DNS) 105 that provides identification androuting identifiers for communications devices operating in wirelesscommunications system 100 based on name requests.

Wireless communications system 100 also includes a rendezvous server(RVS) 110, which operates in conjunction with DNS 105 to providereachability of a host (HIP enabled and/or non-HIP enabled) bymaintaining mappings between an identifier for the host (referred to asa host identification tag (HIT) in HIP) as well as an IP address for thehost. In a wireless communications system utilizing HIP, such aswireless communications system 100, a host may be referred to as amobile host (MH). Any other host which may or may not be in wirelesscommunication system 100 and which is communicating with the MH isreferred to as a correspondent host (CH). The CH may or may not bemobile. A communication session takes place between a MH and a CH. Yetif CH is also mobile, it is then both a MH and a CH.

Wireless communications system 100 also includes a local rendezvousserver (LRVS) 115, which may perform RVS functionality at a local level,such as in a domain. LRVS 115 may also perform Network AddressTranslation (NAT) within a given domain. As shown in FIG. 1 a, LRVS 115may be co-located with a gateway router (GW). Wireless communicationssystem 100 may include a plurality of LRVSs, generally with a LRVS perdomain in wireless communications system 100.

At a level lower than LRVS 115 there may be a number of subnets, witheach subnet containing a Mobility-HIP-Proxy (or Proxy server) (MHP),such as MHP 120 for a first subnet and MHP 122 for a second subnet. Asshown in FIG. 1 a, a MHP may be co-located with an access router(AR)/proxy server. A MHP may perform RVS functionality at a subnetlevel.

Within a single subnet, there may be a number of Base Stations (BS)and/or Access Points (AP), such as BS/AP 125 for the first subnet andBS/AP 127 for the second subnet. A BS/AP may serve as a communicationscontroller for mobile hosts, such as MH, attached to the BS/AP. As shownin FIG. 1 a, BS/AP 125 is serving MH 130. However, since MH 130 may be amobile communications device, MH 130 may move to an area where coverageof BS/AP 125 is poor and may handover to BS/AP 127. MH 130 is shown asMH 132 in FIG. 1 a when it is served by BS/AP 125.

According to an example embodiment, network-based mobility managementfunction is integrated with proxy HIP functions at a MHP to support allhosts (HIP enabled and non-HIP enabled). The hosts are not required topossess new functions including network management and HIP capabilityother than the existing IP protocol stack. Yet the hosts may be able toachieve multi-homing capability and the security level native to awireless communications system using HIP in addition to receivingnetwork-based mobility support.

According to an example embodiment, additional mobility managementfunctions at the access routers taking advantage of the proxy HIPcapability. These additional functions are network-based and includemobile hosts tracking, location update, security signaling, assigning ofnetwork prefix per host identifier, and using the same network prefixwithin the same network domain to avoid duplicate address detection(DAD), resulting in improved handover performance. It also enables amobile host, irrespective of whether it is or is not HIP enabled, to usethe same IP address as long as its points of attachments are within thesame domain.

According to an example embodiment, a MHP (such as MHP 120 or MHP 122)may perform HIP signaling on behalf of a non-HIP enabled MH so that HIPservices may be offered to non-HIP compliant MHs.

According to an example embodiment, a MHP may track movement of a MH.

According to an example embodiment, a MHP may update a MH's bindingrecord. After detection of an attachment of a MH, a MHP may send anupdate message to a nearest anchor point (e.g., a LRVS or RVS) that is across-over point between the MH's old point of attachment and the MH'snew point of attachment.

FIG. 1 b illustrates a table 150 of binding information for a MH.According to an example embodiment, the binding information presented intable 150 may be managed in a hierarchical fashion in a DNS, a RVS, aLRVS, and a MHP. The hierarchical arrangement of the binding informationmay enable the reachability of the MH which may be registered with theMHP.

Once the MH becomes registered, the MHP holds binding information of theHIT of the MH (e.g., HIT(MH)) to the IP address of the MH (e.g.,IP(MH)). While the LRVS holds binding information of the HIT of the MH(i.e., HIT(MH)) to the IP address of the MHP (e.g., IP(MHP)), and theRVS holds binding information of the HIT of the MH (i.e., HIT(MH)) tothe IP address of the LRVS (e.g., IP(LRVS)), and the DNS holds bindinginformation of the HIT of the MH (i.e., HIT(MH)) to the IP address ofthe RVS (e.g., IP(RVS)). The binding information held at the variouslevels of the hierarchy is shown graphically in FIG. 1 a.

FIG. 2 a illustrates a flow diagram of MHP operations 200 as a MHPreceives a packet for a MH. Operations 200 may be indicative ofhigh-level operations occurring in a MHP, such as MHP 120 and MHP 122,as the MHP receives a packet intended for a MH, such as MH 130 and MH132. Operations 200 may occur while the MHP is in a normal operatingmode and has MHs attached or registered.

Operations 200 may begin with the MHP receiving a HIP packet intended(addressed) to the MH (block 205). The MHP may then perform a check todetermine if the MH is a HIP enabled MH (block 207). According to anexample embodiment, the determination may be according to how the MHattaches and registers with the network. A non-HIP host attaches to thenetwork using IP packets without performing HIP registration, whereas aHIP host uses HIP packets and performs HIP registration. According to anexample embodiment, if the MH is a HIP enabled MH, then the packetintended for the MH is a HIP packet, while if the MH is a non-HIPenabled MH, then the packet intended for the MH is an IP packet.According to an example embodiment, the MHP knows the capabilities(e.g., HIP enabled or non-HIP enabled) of the MH when the MH attaches tothe MHP. In general, the MHP may determine if the MH is capable ofperforming an operation or a set of operations.

If the MH is HIP enabled, then the MH is capable of processing the HIPpacket and the MHP may process and/or forward the packet to the MH(block 209). However, if the MH is non-HIP enabled, then the MH isincapable of processing the packet and the MHP may convert the HIPpacket to an IP packet or some other protocol packet (block 211) andthen process and/or forward the packet to the MH (block 213). Ingeneral, process and/or forward may be collectively described asresponding to the packet.

Furthermore, if the MH is HIP enabled, the MHP may provide mobilityfunction support, which may help to make handovers, attachment,detachment, and so forth, more reliable and/or more efficient. If the MHis not HIP enabled, then the MHP may not be able to provide mobilityfunction support.

Although the flow diagram shown in FIG. 2 a (and in other figures shownherein) illustrate support for both HIP enabled and non-HIP enabled MHs,alternatives of the flow diagram(s) exist wherein support for only HIPenabled MHs or non-HIP enabled MHs is provided. Therefore, illustrationand discussion of support for both HIP enabled and non-HIP enabled MHsshould not be construed as being limiting to either the scope or thespirit of the example embodiments.

FIG. 2 b illustrates a flow diagram of MHP operations 250 as a MHPreceives a packet from a MH. Operations 250 may be indicative ofhigh-level operations occurring in a MHP, such as MHP 120 and MHP 122,as the MHP receives a packet from a MH, such as MH 130 and MH 132.Operations 250 may occur while the MHP is in a normal operating mode andhas MHs attached or registered.

Operations 250 may begin with the MHP receiving a packet from the MH(block 255). The MHP may then perform a check to determine if the MH isa HIP enabled MH (block 257). According to an example embodiment, if theMH is a HIP enabled MH, then the packet intended for the MH is a HIPpacket, while if the MH is a non-HIP enabled MH, then the packetintended for the MH is an IP packet. According to an example embodiment,the MHP knows the capabilities (e.g., HIP enabled or non-HIP enabled) ofthe MH when the MH attaches to the MHP. In general, the MHP maydetermine if the MH is capable of performing an operation or a set ofoperations.

If the MH is HIP enabled, then the packet is a HIP packet and may beprocessed and/or forwarded as needed (block 259). However, if the MH isnon-HIP enabled, then the packet is an IP packet (or some otherprotocol) and the MHP may convert the HIP packet to an IP packet (block261) and then process and/or forward the packet as needed (block 263).In general, process and/or forward may be collectively described asresponding to the packet.

FIG. 3 illustrates a wireless communications system 300 with informationhighlights shown for registration of a HIP enabled MH and a non-HIPenabled MH. Wireless communications system 300 includes a DNS 305, a RVS310, a LRVS 315, a first MHP 320, a second MHP 322, a first BS/AP 325, asecond BS/AP 327, a first MH 330, and a second MH 332.

As shown in FIG. 3, first MH 330 is a HIP enabled MH and second MH 332is a non-HIP enabled MH. Both MHs are registering and/or attaching withwireless communications system 300 through first BS/AP 325 and secondBS/AP 327, respectively. The events involved in the registering and/orattaching process are shown in FIG. 3.

First MH 330 may register and attach with wireless communications system300 through first BS/AP 325 to first MHP 320 (shown as event 1A). FirstMHP 320, knowing that first MH 330 is HIP enabled, assigns a HIT forfirst MH 330 and performs a binding information update with LRVS 315(shown as part of event 2A).

According to an example embodiment, first MHP 320 may provide the HITfor first MH 330 (HIT(first MH 330)) as well as its (first MHP 320) IPaddress (IP(first MHP 320)) to LRVS 315. At LRVS 315, if HIT(first MH330) and IP(first MHP 320) are not in binding information stored at LRVS315, then LRVS 315 may store HIT(first MH 330) and IP(first MHP 320) inits binding information (shown as event 3). In general, LVRS 315 havingto update its binding information is an event that is often notperformed since LVRS 315 needs to update its binding information only iffirst MH 330 registers in an MHP (e.g., first MHP 320) that differs froma previous MHP to which it was registered or if first MH 330 isinitially registering with wireless communications system 300.

According to an example embodiment, LRVS 315 also verifies the bindinginformation from first MHP 320 and confirms receipt and successfulprocessing of the binding information from first MHP 320 in a responseto first MHP 320 (shown as even 2A).

According to an example embodiment, as registration process continues(shown as event 4) if LVRS 315 updated its binding information withHIT(first MH 330) and IP(first MHP 320), then LVRS 315 may provide theHIT for first MH 330 (HIT(first MH 330)) as well as its (LVRS 315) IPaddress (IP(LVRS 315)) to RVS 310. At RVS 310, if HIT(first MH 330) andIP(LVRS 315) are not in binding information stored at RVS 310, then RVS310 may store HIT(first MH 330) and IP(LVRS 315) in its bindinginformation (shown as event 4*). In general, VRS 310 having to updateits binding information is an event that is rarely performed since VRS310 needs to update its binding information only if first MH 330registers in an MHP (e.g., first MHP 320) that is anchored by a LVRSthat differs from a previous LVRS to which its previous MHP was anchoredor if first MH 330 is initially registering with wireless communicationssystem 300.

As the registration process continues, first MHP 320 also updates itsbinding information with HIT(first MH 330) and IP(first MH 330) (shownas event 5A). The registration process may complete with first MHP 320performing a router advertisement (RA) of the IP prefix of first MH 330and configuring as well as providing the IP address of first MH 330 tofirst MH 330.

Second MH 332 may attach with wireless communications system 300 throughsecond BS/AP 327 to second MHP 322. Second MHP 322 may detect theattachment of second MH 332 to wireless communications system 300 (shownas event 1B). Second MHP 322, knowing that second MH 332 is non-HIPenabled, assigns a HIT for second MH 332 and performs a bindinginformation update with LRVS 315 (shown as event 2B).

According to an example embodiment, second MHP 322 may provide the HITfor second MH 332 (HIT(second MH 332)) as well as its (second MHP 322)IP address (IP(second MHP 322)) to LRVS 315. At LRVS 315, if HIT(secondMH 332) and IP(second MHP 322) are not in binding information stored atLRVS 315, then LRVS 315 may store HIT(second MH 332) and IP(second MHP322) in its binding information (shown as event 3). In general, LVRS 315having to update its binding information is an event that is often notperformed since LVRS 315 needs to update its binding information only ifsecond MH 332 registers in an MHP (e.g., second MHP 322) that differsfrom a previous MHP to which it was registered or if second MH 332 isinitially registering with wireless communications system 300.

According to an example embodiment, LRVS 315 also verifies the bindinginformation from second MHP 322 and confirms receipt and successfulprocessing of the binding information from second MHP 322 in a responseto second MHP 322 (shown as even 2B).

According to an example embodiment, as attachment (now referred to as anregistration in HIP) process continues (shown as event 4) if LVRS 315updated its binding information with HIT(second MH 332) and IP(secondMHP 322), then LVRS 315 may provide the HIT for second MH 332(HIT(second MH 332)) as well as its (LVRS 315) IP address (IP(LVRS 315))to RVS 310. At RVS 310, if HIT(second MH 332) and IP(LVRS 315) are notin binding information stored at RVS 310, then RVS 310 may storeHIT(second MH 332) and IP(LVRS 315) in its binding information (shown asevent 4*). In general, VRS 310 having to update its binding informationis an event that is rarely performed since VRS 310 needs to update itsbinding information only if second MH 332 registers in an MHP (e.g.,second MHP 322) that is anchored by a LVRS that differs from a previousLVRS to which its previous MHP was anchored or if second MH 332 isinitially registering with wireless communications system 300.

As the registration process continues, second MHP 322 also updates itsbinding information with HIT(second MH 332) and IP(second MH 332) (shownas event 5B). The registration process may complete with second MHP 322performing a RA of the IP prefix of second MH 332 and configuring aswell as providing the IP address of second MH 332 to second MH 332.

After registration, the MH (either first MH 330 or second MH 332) maybecome reachable from any correspondent host (CH) which may query DNS305 about the location of the MH. In response to such a query, DNS 305may reply with the IP address of the RVS to which the HIT of the MH isregistered.

FIG. 4 a illustrates a diagram 400 of messages exchanged betweenentities in a wireless communications system as a non-HIP enabled MHattaches to the wireless communications system. Since the MH is non-HIPenabled, communications between the MH and its MHP occurs with IP (orsome other protocol) packets, which may be translated by the MHP intoHIP packets, while communications between the MHP and other entitiesoccur with HIP packets.

FIG. 4 b illustrates a diagram 420 of messages exchanged betweenentities in a wireless communications system as a HIP enabled MHattaches to the wireless communications system. Since the MH is HIPenabled, communications throughout the attachment process is with HIPpackets.

FIG. 4 c illustrates a flow diagram of MHP operations 440 for attachmentof a HIP enabled MH.

FIG. 4 d illustrates a flow diagram of MHP operations 460 for attachmentof a non-HIP enabled MH.

In addition to providing support for the registration and/or attachmentof a MH to a wireless communications system, a MHP may also enable anexchange of data traffic between a MH (either HIP enabled or non-HIPenabled) and a CH (also either HIP enabled or non-HIP enabled). In orderto support data traffic, a security association (SA) may be establishedprior to the data plane traffic begins. In general, if a MH is a HIPenabled MH, the SA at the MH side ends at the MH, while if the MH is anon-HIP enabled MH, the SA at the MH side ends at the MHP to which theMH is registered. Similarly, at the CH side, if the CH is a HIP enabledCH then the SA may end at the CH, while if the CH is a non-HIP enabledCH, then the SA may end at the MHP to which the CH is registered.

FIG. 5 a illustrates a diagram 500 of messages exchanged betweenentities in a wireless communications system as a non-HIP enabled MH anda CH exchange data traffic, wherein the CH is an initiator of theexchange. Although diagram 500 illustrates the message exchange betweenthe non-HIP enabled MH and a CH that is initiated by the CH, a similarexchange may be initiated by the non-HIP enabled MH. As shown in FIG. 5a, the message exchange may involve entities including: a MH 505 (thenon-HIP enabled MH), a MHP 507 (the MHP to which MH 505 is registered),a LRVS 509, a RVS 511, a DNS 513, and a CH 515 (the CH). Without loss ofgenerality, consider a situation wherein both CH 515 and MH 505 areregistered to the same RVS. If they are not registered to the same RVS,then additional entities, such as LRVS, MHP, and so forth may beinvolved in the message exchanged. However, the spirit of the messageflow remains the same as if both share the same RVS. Therefore tosimplify diagram 500, both CH 515 and MH 505 are considered to beregistered to the same RVS.

Since CH 515 is the initiator of the message exchange, it may be labeledas (I), and MH 505, which is the responder, is labeled as (R). When MH505 attaches to a MHP, MH 505 may first be registered according to aregistration procedure as described above. After registration, MH 505may become reachable to CH 515 which obtains the IP address of MH 505from DNS 513.

Two pairs of initiation-response packets (referred to as I1, R1, 12, R2)may then be exchanged between an initiator (e.g., CH 515) and aresponder (e.g., MH 505) to prepare for the establishment of a SA. Ingeneral, either CH 515 or MH 505 may be the initiator and the responder.

As shown in diagram 500, CH 515 (which may be HIP enabled or non-HIPenabled) may initiate a HIP SA from outside the domain of MH 505 bysending a message (e.g., an I1 packet) to RVS 511 (event 520). CH 515may already have the IP address of RVS 511 (to which MH 505 isregistered) by querying DNS 513. Upon receiving the I1 packet from CH515, RVS 511 checks the destination HIT in the HIP header of the I1packet. If the destination HIT is the HIT of a registered MH, then RVS511 forwards the I1 packet to a registered IP address stored in itsbinding information that is associated with the destination HIT, i.e.,the IP address of LRVS 509.

When LRVS 509 receives the I1 packet forwarded by RVS 511, LRVS 509 maycheck the destination HIT in the HIP header of the I1 packet. If thedestination HIT is the HIT of a registered MH, then LRVS 509 forwardsthe I1 packet to a registered IP address stored in its bindinginformation that is associated with the destination HIT, i.e., the IPaddress of MHP 507. LRVS 509 may also store the binding informationHIT(CH 515) and IP(RVS 511) and IP(CH 515).

When MHP 507 receives the I1 packet from LRVS 509, MHP 507 checks thedestination HIT in the HIP header of the I1 packet. If the destinationHIT is the HIT of a registered MH that is non-HIP enabled (e.g., MH505), then MHP 507 stores the binding information HIT(CH 515) andIP(LRVS 509) and IP(CH 515). MHP 507 may respond to the I1 packet bysending a R1 packet to CH 515 on the behalf of MH 505 to LRVS 509 (event522).

LRVS 509 may check the destination HIT in the HIP header of the R1packet. If the destination HIT is the HIT of a registered CH, then LRVS509 forwards the R1 packet to a registered IP address stored in itsbinding information that is associated with the destination HIT, i.e.,the IP address of CH 515. Since LRVS 509 stored the binding informationHIT(CH 515) and IP(RVS 511) and IP(CH 515) when it processed the I1packet, LRVS 509 may send the R1 packet directly to CH 515.

When CH 515 receives the R1 packet from LRVS 509, CH 515 may store thebinding information HIT(MH 505) and IP(LRVS 509) and IP(MH 505). CH 515may respond to the R1 packet with an I2 packet containing the HIT of MH505 (event 524). Due to its updated binding information, the I2 packetis sent directly to LRVS 509, which may forward it to MHP 507.

MHP 507, again operating on behalf of MH 505 since MH 505 is non-HIPenabled, may respond to the I2 packet with a R2 packet containing theHIT of CH 515 (event 526). The R2 packet may be sent to LRVS 509, whichmay forward the R2 packet to CH 515.

After successful exchange of the two initiation-response packet pairs(IL R1, 12, and R2), a HIP SA will be established between the initiatorand responder (event 528). During the establishment of the SA, all theproxies (e.g., MHP 507) along the path between MH 505 and LRVS 509 willbe aware of the SA context. After establishing the HIP SA, data trafficusing Enhanced Services Plan (ESP) may be exchanged between theinitiator (CH 515) and responder (MH 505) (event 530). However, since MH505 is non-HIP enabled, MHP 507 may de-encapsulate data packets from CH515 and destined for MH 505, i.e., translate HIP packets into IPpackets. MHP 507 may also encapsulate data packets from MH 505 destinedfor CH 515, i.e., translate IP packets into HIP packets.

In general, for a non-HIP enabled host, e.g., MH 505, a MHP acts as aHIP proxy in the data plane. The MHP encapsulates data packetsoriginated from the non-HIP enabled host and de-encapsulates datapackets destined for the non-HIP enabled host.

FIG. 5 b illustrates a diagram 550 of messages exchanged betweenentities in a wireless communications system as a HIP enabled MH and aCH exchange data traffic, wherein the CH is an initiator of theexchange. Although diagram 550 illustrates the message exchange betweenthe HIP enabled MH and a CH that is initiated by the CH, a similarexchange may be initiated by the non-HIP enabled MH. As shown in FIG. 5b, the message exchange may involve entities including: a MH 555 (theHIP enabled MH), a MHP 557 (the MHP to which MH 555 is registered), aLRVS 559, a RVS 561, a DNS 563, and a CH 565 (the CH). Without loss ofgenerality, consider a situation wherein both CH 565 and MH 555 areregistered to the same RVS. If they are not registered to the same RVS,then additional entities, such as LRVS, MHP, and so forth may beinvolved in the message exchanged. However, the spirit of the messageflow remains the same as if both share the same RVS. Therefore tosimplify diagram 550, both CH 565 and MH 555 are considered to beregistered to the same RVS.

Since CH 565 is the initiator of the message exchange, it may be labeledas (I), and MH 555, which is the responder, is labeled as (R). When MH555 attaches to a MHP, MH 555 may first be registered according to aregistration procedure as described above. After registration, MH 555may become reachable to CH 565 which obtains the IP address of MH 555from DNS 563.

Two pairs of initiation-response packets (referred to as I1, R1, 12, R2)may then be exchanged between an initiator (e.g., CH 565) and aresponder (e.g., MH 555) to prepare for the establishment of a SA. Ingeneral, either CH 565 or MH 555 may be the initiator and the responder.

As shown in diagram 550, CH 565 (which may be HIP enabled or non-HIPenabled) may initiate a HIP SA from outside the domain of MH 555 bysending a message (e.g., an I1 packet) to RVS 561 (event 570). CH 565may already have the IP address of RVS 561 (to which MH 555 isregistered) by querying DNS 563. Upon receiving the I1 packet from CH565, RVS 561 checks the destination HIT in the HIP header of the I1packet. If the destination HIT is the HIT of a registered MH, then RVS561 forwards the I1 packet to a registered IP address stored in itsbinding information that is associated with the destination HIT, i.e.,the IP address of LRVS 559.

When LRVS 559 receives the I1 packet forwarded by RVS 561, LRVS 559 maycheck the destination HIT in the HIP header of the I1 packet. If thedestination HIT is the HIT of a registered MH, then LRVS 559 forwardsthe I1 packet to a registered IP address stored in its bindinginformation that is associated with the destination HIT, i.e., the IPaddress of MHP 557. LRVS 559 may also store the binding informationHIT(CH 565) and IP(RVS 561) and IP(CH 565). LRVS 559 may also store thebinding information HI(CH 565) and IP (LRVS 559).

When MHP 557 receives the I1 packet from LRVS 559, MHP 557 checks thedestination HIT in the HIP header of the I1 packet. If the destinationHIT is the HIT of a registered MH that is HIP enabled (e.g., MH 555),then MHP 557 stores the binding information HIT(CH 565) and IP(LRVS 559)and IP(CH 565). MHP 557 may the forward the I1 packet MH 555. MH 555,upon receipt of the I1 packet may respond to the I1 packet by sending aR1 packet to CH 565 by way of MHP 557 (event 572).

MHP 557, after receiving the R1 packet, may check the destination HIT ofthe HIP header of the R1 packet and forward the R1 packet to aregistered IP address associated with the destination HIT, i.e., the IPaddress of LRVS 559. Upon receipt of the R1 packet, LRVS 559 may checkthe destination HIT in the HIP header of the R1 packet. If thedestination HIT is the HIT of a registered CH, then LRVS 559 forwardsthe R1 packet to a registered IP address stored in its bindinginformation that is associated with the destination HIT, i.e., the IPaddress of CH 565. Since LRVS 559 stored the binding information HIT(CH565) and IP(RVS 561) and IP(CH 565) when it processed the I1 packet,LRVS 559 may send the R1 packet directly to CH 565.

When CH 565 receives the R1 packet from LRVS 559, CH 565 may store thebinding information HIT(MH 555) and IP(LRVS 559) and IP(MH 555). CH 565may also store the binding information HIT(CH 565) and IP(CH 565). CH565 may respond to the R1 packet with an I2 packet containing the HIT ofMH 555 (event 574). Due to its updated binding information, the I2packet is sent directly to LRVS 559, which may forward it to MHP 557.

MHP 557 may then forward the I2 packet to MH 555. MH 555, upon receiptof the I2 packet may respond to the I2 packet with a R2 packetcontaining the HIT of CH 565 (event 576). The R2 packet may be sent toMHP 557, which may then forward the R2 packet to LRVS 559, which maythen forward the R2 packet to CH 565.

After successful exchange of the two initiation-response packet pairs(IL R1, 12, and R2), a HIP SA will be established between the initiatorand responder (event 578). During the establishment of the SA, all theproxies (e.g., MHP 557) along the path between MH 555 and LRVS 559 willbe aware of the SA context. After establishing the HIP SA, data trafficusing Enhanced Services Plan (ESP) may be exchanged between theinitiator (CH 565) and responder (MH 555) (event 580). However, since MH555 is HIP enabled, MHP 557 may not need to de-encapsulate data packetsfrom CH 565 and destined for MH 555, i.e., translate HIP packets into IPpackets. MHP 557 may not need to also encapsulate data packets from MH555 destined for CH 565, i.e., translate IP packets into HIP packets.

FIG. 5 c illustrates a flow diagram of MHP operations 590 in theestablishing of a data traffic exchange between a HIP enabled MH and aHIP enabled CH.

FIG. 5 d illustrates a flow diagram of MHP operations 595 in theestablishing of a data traffic exchange between a non-HIP enabled MH anda HIP enabled CH.

FIG. 6 a illustrates a wireless communications system 600 withinformation highlights shown for a flow of an I1 packet from a CH to aMH.

FIG. 6 b illustrates a wireless communications system 650 withinformation highlights shown for a flow of I1, R1, 12, and R2 packetsfrom a CH to a MH.

As a MH moves around, it may be necessary for the MH to participate in ahandover, wherein the MH changes access networks. A handover may benecessary because the MH has moved to an area where a current accessnetwork has poor or no coverage and a new access network has bettercoverage. Different handover scenarios may occur, including but notlimited to: the MH either being HIP enabled or non-HIP enabled, thecurrent access network and the new access network belonging to a singledomain managed by a single LVRS, the current access network and the newaccess network belonging to different domains managed by differentLVRSs, and so forth.

A non-HIP enabled MH may change its point of access (a current MHP fromthe current access network) and attach to a new MHP from the new accessnetwork under the same LRVS. The new access network may be of the sameor different network type as the previous access network. Irrespectiveof the type of access network to which the new MHP is connected andirrespective of whether the MH is HIP enabled or non-HIP enabled, thenew MHP will be informed about the attachment of the arriving MH. Thenew MHP acts as the HIP proxy. The new MHP also updates the bindingrecord of the MH at the LRVS. To do that, the new MHP needs to know thecontext of the HIP SA and the HIT of the MH. Generally, a mechanism tosecurely share this security context with the proxies that MH moves tois needed.

FIG. 7 a illustrates a diagram 700 of messages exchanged betweenentities in a wireless communications system as a non-HIP enabled MHhandovers from a current access network and a new access network withboth access networks belonging to a single domain managed by a singleLRVS, i.e., an intra-domain handover. Furthermore, the MH iscommunicating with a HIP enabled CH in a different domain but both theMH and the CH are registered at the same RVS. The message exchange mayinvolve entities including: a MH 705, a first MHP 707 (MHP for thecurrent access network), a second MHP 709 (MHP for the new accessnetwork), and a LRVS 711. Since both the MH and the CH are registered atthe same RVS, some entities, such as a RVS and a DNS, may not need to beshown. Furthermore, the CH is not shown to maintain simplicity ofdiagram 700.

As part of the handover procedure, MH 705 may detach from first MHP 707(event 715). Since MH 705 is no longer served by first MHP 707, firstMHP 707 may delete binding information related to MH 705. Additionally,first MHP 707 may send an update packet to LRVS 711 to inform LRVS 711that MH 705 is no longer being served by first MHP 707. At LRVS 711,LRVS 711 may deregister first MHP 707 by removing binding informationrelated to first MHP 707 and MH 705, such as HIT(MH 705) and IP(firstMHP 707).

First MHP 707 may also provide updates regarding MH 705 to some or allof its neighboring MHPs, for example, first MHP 707 may send an updateto second MHP 709 (event 717). According to an example embodiment, firstMHP 707 may send the update to second MHP 709, which may include bindinginformation HIT(MH 705), by way of a security context or from LRVS 711.The same binding information HIT(MH 705) may be used.

MH 705 may then attach to second MHP 709 (event 719). Since MH 705 is anon-HIP enabled MH, second MHP 709 may need to detect the attachment ofMH 705. Second MHP 709 may make use of the binding information providedby first MHP 707. Second MHP 709 may send an update to LRVS 711, whichmay update its binding information with HIT(MH 705) and IP(second MHP709).

In general, when a non-HIP enabled MH attaches to a MHP, such as secondMHP 709, the MHP may register the MH using a registration procedure asdiscussed previously and assigns a HIT to the MH (e.g., HIT(MH 705) forMH 705).

For a non-HIP enabled MH, the MHP may act as the HIP proxy in the dataplane.

A GW, which may be co-located with LRVS 711, may be in charge of IPprefix allocation. The GW has knowledge that MH 705 with HIT(MH 705)being attached to second MHP 709 is the same MH that is being detachedfrom first MHP 707. The GW may then inform second MHP 709 that the IPprefix was previously assigned to MH 705.

LRVS 711 may inform second MHP 709 of the successful update with aresponse (event 721). When second MHP 709 receives the response fromLRVS 711, second MHP 709 may send a RA to MH 705 (event 723). Second MHP709 may have knowledge regarding MH 705 with HIT(MH 705). The RA sent bysecond MHP 709 may have the same network prefix that MH 705 hadpreviously used with first MHP 707 to configure its IP address. MH 705therefore retains the same IP address configuration so that duplicateaddress detection (DAD) is not needed. Not having to use DAD maysignificantly reduce handover latency and signaling overhead, therebyresulting in shorter handover delay and potentially fewer packets lost.

Furthermore, the use of the same IP address in intra-domain handoveralso supports location privacy.

FIG. 7 b illustrates a flow diagram of current MHP operations 760 as anon-HIP enabled MH handovers from a current access network and a newaccess network with both access networks belonging to a single domainmanaged by a single LRVS.

FIG. 7 c illustrates a flow diagram of new MHP operations 780 as anon-HIP enabled MH handovers from a current access network and a newaccess network with both access networks belonging to a single domainmanaged by a single LRVS.

FIG. 8 a illustrates a diagram 800 of messages exchanged betweenentities in a wireless communications system as a HIP enabled MHhandovers from a current access network and a new access network withboth access networks belonging to a single domain managed by a singleLRVS, i.e., an intra-domain handover. Furthermore, the MH iscommunicating with a HIP enabled CH in a different domain but both theMH and the CH are registered at the same RVS. The message exchange mayinvolve entities including: a MH 805, a first MHP 807 (MHP for thecurrent access network), a second MHP 809 (MHP for the new accessnetwork), and a LRVS 811. Since both the MH and the CH are registered atthe same RVS, some entities, such as a RVS and a DNS, may not need to beshown. Furthermore, the CH is not shown to maintain simplicity ofdiagram 800.

As part of the handover procedure, MH 805 may detach from first MHP 807(event 815). Since MH 805 is no longer served by first MHP 807, firstMHP 807 may delete binding information related to MH 805. Additionally,first MHP 807 may send an update packet to LRVS 811 to inform LRVS 811that MH 805 is no longer being served by first MHP 807. At LRVS 811,LRVS 811 may deregister first MHP 807 by removing binding informationrelated to first MHP 807 and MH 805, such as HIT(MH 805) and IP(firstMHP 807).

First MHP 807 may also provide updates regarding MH 805 to some or allof its neighboring MHPs, for example, first MHP 807 may send an updateto second MHP 809 (event 817). According to an example embodiment, firstMHP 807 may send the update to second MHP 809, which may include bindinginformation HIT(MH 805), by way of a security context or from LRVS 811.The same binding information HIT(MH 805) may be used.

MH 805 may then attach to and register with second MHP 809 (event 819).Second MHP 809 may make use of the binding information provided by firstMHP 807. Second MHP 809 may send an update to LRVS 811, which may updateits binding information with HIT(MH 805) and IP(second MHP 809).

In general, when a HIP enabled MH attaches to a MHP, such as second MHP809, the MHP may register the MH using a registration procedure asdiscussed previously and assigns a HIT to the MH (e.g., HIT(MH 805) forMH 805).

A GW, which may be co-located with LRVS 811, may be in charge of IPprefix allocation. The GW has knowledge that MH 805 with HIT(MH 805)being attached to second MHP 809 is the same MH that is being detachedfrom first MHP 807. The GW may then inform second MHP 809 that the IPprefix was previously assigned to MH 805.

LRVS 811 may inform second MHP 809 of the successful update with aresponse (event 821). When second MHP 809 receives the response fromLRVS 811, second MHP 809 may send a RA to MH 805 (event 823). Second MHP809 may have knowledge regarding MH 805 with HIT(MH 805). The RA sent bysecond MHP 809 may have the same network prefix that MH 805 hadpreviously used with first MHP 807 to configure its IP address. MH 805therefore retains the same IP address configuration so that duplicateaddress detection (DAD) is not needed. Not having to use DAD maysignificantly reduce handover latency and signaling overhead, therebyresulting in shorter handover delay and potentially fewer packets lost.

The use of the same IP address enables the MH (a HIP enabled MH) to usethe established HIP associations during and after the handover as thecommunication context remains the same. Therefore the re-establishmentof HIP SA is not required, resulting in time reduction to performinitiation-response exchange to further reduce the handover delay.

Furthermore, the use of the same IP address in intra-domain handoveralso supports location privacy.

FIG. 8 b illustrates a flow diagram of current MHP operations 860 as aHIP enabled MH handovers from a current access network and a new accessnetwork with both access networks belonging to a single domain managedby a single LRVS.

FIG. 8 c illustrates a flow diagram of new MHP operations 880 as a HIPenabled MH handovers from a current access network and a new accessnetwork with both access networks belonging to a single domain managedby a single LRVS.

FIG. 9 a illustrates a diagram 900 of messages exchanged betweenentities in a wireless communications system as a non-HIP enabled MHhandovers from a current access network and a new access network withthe access networks belonging to different domain managed by differentLRVS, i.e., an inter-domain handover. Furthermore, the MH iscommunicating with a HIP enabled CH in CH in a different domain but boththe MH and the CH are registered at the same RVS. The message exchangemay involve entities including: a MH 905, a first MHP 907 (MHP for thecurrent access network), a second MHP 909 (MHP for the new accessnetwork), a first LRVS 911 (LRVS for the current access network), and asecond LRVS 913 (LRVS for the new access network). Since both the MH andthe CH are registered at the same RVS, some entities, such as a RVS anda DNS, may not need to be shown. Furthermore, the CH is not shown tomaintain simplicity of diagram 900.

According to an example embodiment, since the handover is not under thesame LRVS (i.e., an inter-domain handover), the current MHP (first MHP907) may send update information packet1 to the current LRVS (first LRVS911), whereas the new MHP (second MHP 909) may send update informationto the new LRVS (second LRVS 913). The new LRVS (second LRVS 913) mayhave no record of the HIT of the MH (HIT(MH 905)) attaching to secondMHP 909. Second LRVS 913 may therefore assign a new IP prefix to MH 905.With a new IP prefix, it is then necessary to perform DAD and toestablish a new SA.

As part of the handover procedure, MH 905 may detach from first MHP 907(event 915). Since MH 905 is no longer served by first MHP 907, firstMHP 907 may delete binding information related to MH 905. Additionally,first MHP 907 may send an update packet to first LRVS 911 to informfirst LRVS 911 that MH 905 is no longer being served by first MHP 907.At first LRVS 911, first LRVS 911 may deregister first MHP 907 byremoving binding information related to first MHP 907 and MH 905, suchas HIT(MH 905) and IP(first MHP 907).

MH 905 may then attach to second MHP 909 (event 917). Since MH 905 is anon-HIP enabled MH, second MHP 909 may need to detect the attachment ofMH 905. Second MHP 909 may send an update to second LRVS 913, which mayupdate its binding information with HIT(MH 905) and IP(second MHP 909).

In general, when a non-HIP enabled MH attaches to a MHP, such as secondMHP 909, the MHP may register the MH using a registration procedure asdiscussed previously and assigns a HIT to the MH (e.g., HIT(MH 905) forMH 905).

Second LRVS 913 may inform second MHP 909 of the successful update witha response (event 919). When second MHP 909 receives the response fromsecond LRVS 913, second MHP 909 may send a RA to MH 905 (event 921).Second MHP 909 may not have knowledge regarding MH 905 with HIT(MH 905).The RA sent by second MHP 909 may have a different network prefix thatMH 905 had previously used with first MHP 907 to configure its IPaddress. MH 905 therefore is unlikely to have the same IP addressconfiguration so DAD is likely to be needed. Second LRVS 913 may alsoestablish a new SA with second MHP 909.

It may be possible that the new LRVS (second LRVS 913) and the currentLRVS (first LRVS 911) belong to different RVSs. In such a situation, MH905 may need to perform registration as discussed above.

FIG. 9 b illustrates a flow diagram of current MHP operations 960 as anon-HIP enabled MH handovers from a current access network and a newaccess network with the access networks belonging to different domainmanaged by different LRVS.

FIG. 9 c illustrates a flow diagram of new MHP operations 980 as anon-HIP enabled MH handovers from a current access network and a newaccess network with the access networks belonging to different domainmanaged by different LRVS.

FIG. 10 a illustrates a diagram 1000 of messages exchanged betweenentities in a wireless communications system as a HIP enabled MHhandovers from a current access network and a new access network withthe access networks belonging to different domain managed by differentLRVS, i.e., an inter-domain handover. Furthermore, the MH iscommunicating with a HIP enabled CH in CH in a different domain but boththe MH and the CH are registered at the same RVS. The message exchangemay involve entities including: a MH 1005, a first MHP 1007 (MHP for thecurrent access network), a second MHP 1009 (MHP for the new accessnetwork), a first LRVS 1011 (LRVS for the current access network), and asecond LRVS 1013 (LRVS for the new access network). Since both the MHand the CH are registered at the same RVS, some entities, such as a RVSand a DNS, may not need to be shown. Furthermore, the CH is not shown tomaintain simplicity of diagram 1000.

According to an example embodiment, since the handover is not under thesame LRVS (i.e., an inter-domain handover), the current MHP (first MHP1007) may send update information packet1 to the current LRVS (firstLRVS 1011), whereas the new MHP (second MHP 1009) may send updateinformation to the new LRVS (second LRVS 1013). The new LRVS (secondLRVS 1013) may have no record of the HIT of the MH (HIT(MH 1005))attaching to second MHP 1009. Second LRVS 1013 may therefore assign anew IP prefix to MH 1005. With a new IP prefix, it is then necessary toperform DAD and to establish a new SA.

As part of the handover procedure, MH 1005 may detach from first MHP1007 (event 1015). Since MH 1005 is no longer served by first MHP 1007,first MHP 1007 may delete binding information related to MH 1005.Additionally, first MHP 1007 may send an update packet to first LRVS1011 to inform first LRVS 1011 that MH 1005 is no longer being served byfirst MHP 1007. At first LRVS 1011, first LRVS 10911 may deregisterfirst MHP 1007 by removing binding information related to first MHP 1007and MH 1005, such as HIT(MH 1005) and IP(first MHP 1007).

MH 1005 may then attach to and register with second MHP 1009 (event1017). Second MHP 1009 may send an update to second LRVS 1013, which mayupdate its binding information with HIT(MH 1005) and IP(second MHP1009).

In general, when a HIP enabled MH attaches to a MHP, such as second MHP1009, the MHP may register the MH using a registration procedure asdiscussed previously and assigns a HIT to the MH (e.g., HIT(MH 1005) forMH 1005).

Second LRVS 1013 may inform second MHP 1009 of the successful updatewith a response (event 1019). When second MHP 1009 receives the responsefrom second LRVS 1013, second MHP 1009 may send a RA to MH 1005 (event1021). Second MHP 1009 may not have knowledge regarding MH 1005 withHIT(MH 1005). The RA sent by second MHP 1009 may have a differentnetwork prefix that MH 1005 had previously used with first MHP 1007 toconfigure its IP address. MH 1005 therefore is unlikely to have the sameIP address configuration so DAD is likely to be needed. Second LRVS 1013may also establish a new SA with second MHP 1009.

It may be possible that the new LRVS (second LRVS 1013) and the currentLRVS (first LRVS 1011) belong to different RVSs. In such a situation, MH1005 may need to perform registration as discussed above.

FIG. 10 b illustrates a flow diagram of current MHP operations 1060 as aHIP enabled MH handovers from a current access network and a new accessnetwork with the access networks belonging to different domain managedby different LRVS.

FIG. 10 c illustrates a flow diagram of new MHP operations 1080 as a HIPenabled MH handovers from a current access network and a new accessnetwork with the access networks belonging to different domain managedby different LRVS.

According to an example embodiment, having a proxy may also eliminatethe need for a new location reachability check between the MH and itspeers, because the new location of the MH is known to the MH's MHP. Anumber of proxies in a domain may depend on the domain's size and eachsubnet is managed by a MHP which acts as an authoritative proxy for thatsubnet. When an authoritative proxy is not functional, its subnet may bemanaged by a neighboring proxy. The number of MHs in each subnet may notexceed the capability of the proxy.

According to an example embodiment, “double move” scenarios where the MHand the CH perform handovers at the same time may also be managed by theembodiments described herein. Furthermore, multi-homing is also managed.

FIG. 11 provides an alternate illustration of a communications device1100. Communications device 1100 may be an implementation of a MHP.Communications device 1100 may be used to implement various ones of theembodiments discussed herein. As shown in FIG. 11, a transmitter 1105 isconfigured to transmit information and a receiver 1110 is configured toreceive information.

A packet translating unit 1120 is configured to translate packets from afirst format (e.g., HIP) into a second format (e.g., IP) and vice versa.A packet processing unit 1122 is configured to process a packet based ona nature of the packet. A binding information computing unit 1124 isconfigured to compute binding information based on presence of bindinginformation stored in a memory 1145, a database, or so forth.

A binding information managing unit 1126 is configured to manage (e.g.,determine if binding information needs to be updated, modified, added,deleted, or so forth) binding information stored in memory 1145,database, or so forth. A RA unit 1128 is configured to perform routeradvertisement. A DAD unit 1130 is configured to participate in duplicateaddress detection. A SA unit 1132 is configured to establish a securityassociation. A forwarding unit 1134 is configured to forward packetsbased on binding information and/or header information.

A host determining unit 1136 is configured to determine a nature of ahost (e.g., is the host HIP enabled or non-HIP enabled). An addressingunit 1138 is configured to configure an addressing identifier (e.g., anIP address) for a communications device. Collectively, bindinginformation managing unit 1126, RA unit 1128, DAD unit 1130, and SA unit1132 may help to support mobility functions in a HIP enabled host. Amemory 1145 is configured to store information, such as bindinginformation, as well as packets, and so on.

The elements of communications device 1100 may be implemented asspecific hardware logic blocks. In an alternative, the elements ofcommunications device 1100 may be implemented as software executing in aprocessor, controller, application specific integrated circuit, or soon. In yet another alternative, the elements of communications device1100 may be implemented as a combination of software and/or hardware.

As an example, transmitter 1105 and receiver 1110 may be implemented asa specific hardware block, while packet translating unit 1120, packetprocessing unit 1122, binding information computing unit 1124, bindinginformation managing unit 1126, RA unit 1128, DAD unit 1130, SA unit1132, forwarding unit 1134, host determining unit 1136, and addressingunit 1138 may be software modules executing in a microprocessor (such asprocessor 1115), a custom circuit, a custom compiled logic array of afield programmable logic array, or combinations thereof.

The above described embodiments of communications device 1100 may alsobe illustrated in terms of methods comprising functional steps and/ornon-functional acts. The previous description and related flow diagramsillustrate steps and/or acts that may be performed in practicing exampleembodiments of the present invention. Usually, functional steps describethe invention in terms of results that are accomplished, whereasnon-functional acts describe more specific actions for achieving aparticular result. Although the functional steps and/or non-functionalacts may be described or claimed in a particular order, the presentinvention is not necessarily limited to any particular ordering orcombination of steps and/or acts. Further, the use (or non use) of stepsand/or acts in the recitation of the claims—and in the description ofthe flow diagrams(s) for FIGS. 2 a, 2 b, 4 c, 4 d, 5 c, 5 d, 7 b, 7 c, 8b, 8 c, 9 b, 9 c, 10 b, and 10 c—is used to indicate the desiredspecific use (or non-use) of such terms.

Advantageous features of embodiments of the invention may include: amethod or system to enable network-based mobility management to both HIPand non-HIP hosts by integrating a network-based mobility managementfunction and proxy HIP function at the network access router.

Advantageous features of embodiments of the invention may include: amethod or system to improve handover performance for both HIP andnon-HIP hosts by integrating a network-based mobility managementfunction and proxy HIP function at the network access router. Thenetwork-based mobility management function may include mobile hoststracking, location update, security signaling, assigning of networkprefix per host identifier, and using the same network prefix within thesame network domain to avoid duplicate address detection (DAD).

Advantageous features of embodiments of the invention may include: amethod or system to enable a mobile host, which may or may not beHIP-enabled, may move from one access network to another access networkin the same domain without changing its IP address while communicatingwith a correspondent host, which may or may not be HIP-enabled, in thesame or different domain.

Advantageous features of embodiments of the invention may include: amethod or system to enable a mobile host, which may or may not beHIP-enabled, may handover from one type of wireless interface (such asWLAN) to a different type of wireless interface (such as WiMAX) in thesame domain without changing its IP address while communicating with acorrespondent host, which may or may not be HIP-enabled, in the same ordifferent domain.

Advantageous features of embodiments of the invention may include: amethod or system to enable a mobile host, which may or may not beHIP-enabled, may move from one access network in one domain to anotheraccess network in a different domain while communicating with acorrespondent host, which may or may not be HIP-enabled. Its IP addressmay change.

Advantageous features of embodiments of the invention may include:methods disclosed above wherein both the MH and the CH move (participatein handovers) simultaneously.

Advantageous features of embodiments of the invention may include: amethod for proxy operations, the method comprising: determining if acommunications device is capable of performing an operation; forwardinga transmission to a destination of the transmission if thecommunications device is capable of performing an operation; andresponding to the transmission on behalf of the communications device ifthe communications device is not capable of performing an operation.

The method could further include, wherein determining if acommunications device is capable of performing an operation comprisesdetermining if the communications device is capable of supporting acommunications protocol. The method could further include, wherein thecommunications protocol supports multiple identifiers for a singlecommunications entity. The method could further include, wherein themultiple identifiers comprises a first identifier for identificationpurposes and a second identifier for addressing purposes. The methodcould further include, wherein the communications protocol comprises aHost Identity Protocol. The method could further include, whereinresponding to the transmission comprises: processing the transmission;and forwarding the transmission to the destination of the transmission.The method could further include, wherein responding to the transmissionfurther comprises translating the transmission from a first format to asecond format. The method could further include, wherein the destinationis the communications device, and wherein the translating comprisesde-encapsulating the transmission. The method could further include,wherein a source of the transmission is the communications device, andwherein the translating comprises encapsulating the transmission.

Advantageous features of embodiments of the invention may include: aproxy comprising: a host determining unit configured to determine if acommunications device is capable of performing an operation; aforwarding unit coupled to the host determining unit, the forwardingunit configured to forward a transmission to a destination of thetransmission if communications device is capable of performing anoperation; and a response unit coupled to the host determining unit, theresponse unit configured to respond to the transmission on behalf of thecommunications device if the communications device is not capable ofperforming an operation.

The method could further include, wherein the response unit comprises apacket processing unit configured to process the transmission. Themethod could further include, wherein the response unit furthercomprises a packet translating unit coupled to the packet processingunit, the packet translating unit is configured to translate thetransmission from a first format to a second format.

Advantageous features of embodiments of the invention may include: amethod for proxy operations, the method comprising: determining that acommunications device is attaching to a communications system; assigningan identifier for the communications device; updating bindinginformation for the communications device at a server, wherein thebinding information comprises the identifier; and configuring anaddressing identifier for the communications device.

The method could further include, wherein determining that acommunications device is attaching comprises detecting transmissionsfrom the communications device, wherein the transmissions comprisemessages exchanged in order for the communications device to attach tothe communications system. The method could further include, whereindetermining that a communications device is attaching comprisesreceiving an attach message from the communications device. The methodcould further include, wherein the identifier is used foridentification. The method could further include, wherein updatingbinding information comprises transmitting the identifier and anaddressing identifier for the proxy. The method could further include,wherein the binding information is transmitted to the server. The methodcould further include, further comprising receiving a response from theserver, wherein the response comprises configuration information. Themethod could further include, wherein configuring an addressingidentifier for the communications device is based on the configurationinformation. The method could further include, further comprisingtransmitting the addressing identifier for the communications device tothe communications device.

Advantageous features of embodiments of the invention may include: aproxy comprising: a packet processing unit configured to determine if acommunications device is attaching to a communications system; a bindinginformation computing unit coupled to the packet processing unit, thebinding information computing unit configured to assign an identifier tothe communications device; a binding information managing unit coupledto the packet processing unit, the binding information managing unitconfigured to manage changes in the binding information; and anaddressing unit coupled to the packet processing unit, the addressingunit configured to configure an addressing identifier for thecommunications device.

The method could further include, wherein packet processing unitdetermines if a communications device is attaching to the communicationssystem by detecting messages exchanged between the communications deviceand a network entity in the communications system, wherein the messagesare exchanged in an attachment process. The method could furtherinclude, wherein packet processing unit determines if a communicationsdevice is attaching to the communications system by detecting atransmission from the communications device to the proxy requestingattachment. The method could further include, wherein the bindinginformation managing unit causes a transmission of the identifier and anaddressing identifier to a server. The method could further include,wherein the addressing unit configures the addressing identifier basedon configuration information received from a server.

Advantageous features of embodiments of the invention may include: amethod for proxy operations, the method comprising: determining that acommunications device is detaching from a communications system;updating binding information for the communications device at a server;and providing binding information for the communications device toneighboring proxies.

The method could further include, wherein determining that acommunications device is detaching comprises detecting transmissionsfrom the communications device, wherein the transmissions comprisemessages exchanged in order for the communications device to detach fromthe communications system. The method could further include, whereindetermining that a communications device is attaching comprisesreceiving an attach message from the communications device. The methodcould further include, wherein updating binding information comprisestransmitting a request to remove binding information related to thecommunications device and the proxy from the server. The method couldfurther include, wherein providing binding information comprisestransmitting binding information related to the communications device tothe neighboring proxies.

Advantageous features of embodiments of the invention may include: aproxy comprising: a packet processing unit configured to determine if acommunications device is detaching from a communications system; and abinding information managing unit coupled to the packet processing unit,the binding information managing unit configured to manage changes inthe binding information and to generate a binding information update forneighboring proxies.

The method could further include, wherein packet processing unitdetermines if a communications device is attaching to the communicationssystem by detecting messages exchanged between the communications deviceand a network entity in the communications system, wherein the messagesare exchanged in an attachment process. The method could furtherinclude, wherein packet processing unit determines if a communicationsdevice is attaching to the communications system by detecting atransmission from the communications device to the proxy requestingattachment. The method could further include, wherein the bindinginformation managing unit causes a transmission of a request to removingbinding information related to the communications device and to theproxy from a server. The method could further include, wherein thebinding information managing unit causes a transmission of bindinginformation related to the communications device to the neighboringproxies.

Advantageous features of embodiments of the invention may include: amethod for proxy operations, the method comprising: determining that acommunications device is attaching to a communications system, whereinthe communications device was previously attached to the communicationssystem through an alternate proxy; updating binding information for thecommunications device at a server; and configuring an addressingidentifier for the communications device.

The method could further include, further comprising establishing asecurity association with the server for the communications device. Themethod could further include, wherein configuring an addressingidentifier comprises: configuring the addressing identifier based onconfiguration information received from the server; and ensuring thatthe addressing identifier is unique. The method could further include,wherein the configuration information is received in a response from theserver.

Advantageous features of embodiments of the invention may include: aproxy comprising: a packet processing unit configured to determine if acommunications device is attaching to a communications system, whereinthe communications device was previously attached to the communicationssystem through an alternate proxy; a binding information managing unitcoupled to the packet processing unit, the binding information managingunit configured to manage changes in the binding information; and anaddressing unit coupled to the packet processing unit, the addressingunit configured to configure an addressing identifier for thecommunications device.

The method could further include, wherein the addressing unit is furtherconfigured to ensure that the addressing identifier is unique. Themethod could further include, further comprising a securing associationcreating unit coupled to the packet processing unit, the securityassociation creating unit configured to establish a security associationbetween the proxy and a server for the communications device.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions andalterations can be made herein without departing from the spirit andscope of the invention as defined by the appended claims.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure of the present invention, processes,machines, manufacture, compositions of matter, means, methods, or steps,presently existing or later to be developed, that perform substantiallythe same function or achieve substantially the same result as thecorresponding embodiments described herein may be utilized according tothe present invention. Accordingly, the appended claims are intended toinclude within their scope such processes, machines, manufacture,compositions of matter, means, methods, or steps.

What is claimed is:
 1. A method for proxy server operations, the methodcomprising: determining, by the proxy server, if a communications deviceis capable of performing operations of a communications protocol;forwarding, by the proxy server, a transmission to a destination of thetransmission in response to the communications device being capable ofperforming the operations; and responding, by the proxy server, to thetransmission on behalf of the communications device in response to thecommunications device not being capable of performing the operations. 2.The method of claim 1, wherein the communications protocol comprises ahost identity protocol.
 3. The method of claim 1, wherein determining ifthe communications device is capable of performing the operationscomprises determining if the communications device is capable ofsupporting the communications protocol.
 4. The method of claim 3,wherein the communications protocol supports multiple identifiers for asingle communications device.
 5. The method of claim 4, wherein themultiple identifiers comprise a first identifier for identificationpurposes and a second identifier for addressing purposes.
 6. The methodof claim 1, wherein forwarding the transmission comprises: processingthe transmission; and sending the processed transmission to thedestination of the transmission.
 7. The method of claim 6, whereinresponding to the transmission further comprises translating thetransmission from a first format to a second format.
 8. The method ofclaim 7, wherein the destination is the communications device, andwherein the translating comprises de-encapsulating the transmission. 9.The method of claim 7, wherein a source of the transmission is thecommunications device, and wherein the translating comprisesencapsulating the transmission.
 10. The method of claim 1, furthercomprising providing mobility support in response to the communicationsdevice being capable of performing the operations.
 11. A proxy servercomprising: a processor; and a non-transitory computer readable storagemedium storing programming for execution by the processor, theprogramming including instructions for: determining if a communicationsdevice is capable of performing operations of a communications protocol;forwarding a transmission to a destination of the transmission inresponse to the communications device being capable of performing theoperations of the communications protocol; and responding to thetransmission on behalf of the communications device in response to thecommunications device not being capable of performing the operations ofthe communications protocol.
 12. The proxy server of claim 11, whereinthe instructions for forwarding the transmission to the destination ofthe transmission include instructions for: processing the transmission;and sending the processed transmission to the destination of thetransmission.
 13. The proxy server of claim 12, wherein the programmingincludes further instructions for translating the transmission from afirst format to a second format.
 14. The proxy server of claim 13,wherein the destination is the communications device, and wherein theinstructions for translating the transmission include instructions forde-encapsulating the transmission.
 15. The proxy server of claim 13,wherein a source of the transmission is the communications device, andwherein the instructions for translating the transmission includeinstructions for encapsulating the transmission.
 16. The proxy server ofclaim 11, wherein the programming includes further instructions forproviding mobility support to communications devices capable ofperforming the operations of the communications protocol.
 17. The proxyserver of claim 11, wherein the communications protocol comprises a hostidentity protocol.
 18. The proxy server of claim 11, wherein theinstructions for determining if the communications device is capable ofperforming the operations include instructions for determining if thecommunications device is capable of supporting the communicationsprotocol.
 19. The proxy server of claim 18, wherein the communicationsprotocol supports multiple identifiers for a single communicationsdevice.
 20. The proxy server of claim 19, wherein the multipleidentifiers comprise a first identifier for identification purposes anda second identifier for addressing purposes.